⚡ 30 秒速记

• 状态入口集中到动作与派发
• 归约函数根据旧状态计算新状态
• 订阅负责通知，视图再读取所需数据
• 归约过程中禁止再次派发
• 约束换取可追踪性，但不是所有状态都要全局化

Redux 用一条明确的数据流约束状态变化，让发生了什么和为什么变化更容易追踪。 界面派发动作，归约函数计算结果，存储保存后通知订阅者。计算阶段不能再递归派发，否则状态更新会互相嵌套而难以定义。复杂共享状态可以从这套约束中受益，简单局部交互则不必全部搬进去，工具解决的是协作与可预测性问题。

版本校准： 本文若分析 ReactDOM.render、旧生命周期或栈调和，应把它视为理解架构演进的历史路径。React 19 已移除 ReactDOM.render，当前客户端入口使用 createRoot；并发渲染也必须区分可中断的渲染阶段与同步提交阶段。迁移前对照 React 19 官方升级指南。

Redux 背后的架构思想——认识 Flux 架构

Redux 的设计在很大程度上受益于 Flux 架构，我们可以认为 Redux 是 Flux 的一种实现形式（虽然它并不严格遵循 Flux 的设定），理解 Flux 将帮助你更好地从抽象层面把握 Redux。

Flux 并不是一个具体的框架，它是一套由 Facebook 技术团队提出的应用架构，这套架构约束的是应用处理数据的模式。在 Flux 架构中，一个应用将被拆分为以下 4 个部分。

• View（视图层）：用户界面。该用户界面可以是以任何形式实现出来的，React 组件是一种形式，Vue、Angular 也完全 OK。Flux 架构与 React 之间并不存在耦合关系。
• Action（动作）：也可以理解为视图层发出的“消息”，它会触发应用状态的改变。
• Dispatcher（派发器）：它负责对 action 进行分发。
• Store（数据层）：它是存储应用状态的“仓库”，此外还会定义修改状态的逻辑。store 的变化最终会映射到 view 层上去。

这 4 个部分之间的协作将通过下图所示的工作流规则来完成配合：

一个典型的 Flux 工作流是这样的：用户与 View 之间产生交互，通过 View 发起一个 Action；Dispatcher 会把这个 Action 派发给 Store，通知 Store 进行相应的状态更新。Store 状态更新完成后，会进一步通知 View 去更新界面。

值得注意的是，图中所有的箭头都是单向的，这也正是 Flux 架构最核心的一个特点——单向数据流。

Flux 架构到底解决了什么问题

Flux 的核心特征是单向数据流，要想完全了解单向数据流的好处，我们需要先了解双向数据流带来了什么问题

MVC 模式在前端场景下的局限性

双向数据流最为典型的代表就是前端场景下的 MVC 架构，该架构的示意图如下图所示

除了允许用户通过 View 层交互来触发流程以外，MVC 架构还有另外一种形式，即允许用户通过直接触发 Controller 逻辑来触发流程，这种模式下的架构关系如下图所示：